Games of Daze

home *** CD-ROM | disk | FTP | other *** search

/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / formats / ss0288 / ss0288_1.txt < prev next >

Wrap

Text File | 1992-06-01 | 33KB | 750 lines

====================================================================== Microsoft Product Support Services Application Note (Text File) SS0288: RELOCATABLE OBJECT MODULE FORMAT ====================================================================== Revision Date: 5/92 No Disk Included The following information applies to to the Microsoft products listed below. -------------------------------------------------------------------- | INFORMATION PROVIDED IN THIS DOCUMENT AND ANY SOFTWARE THAT MAY | | ACCOMPANY THIS DOCUMENT (collectively referred to as an | | Application Note) IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY | | KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO | | THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A | | PARTICULAR PURPOSE. The user assumes the entire risk as to the | | accuracy and the use of this Application Note. This Application | | Note may be copied and distributed subject to the following | | conditions: 1) All text must be copied without modification and | | all pages must be included; 2) If software is included, all files | | on the disk(s) must be copied without modification [the MS-DOS(R) | | utility DISKCOPY is appropriate for this purpose]; 3) All | | components of this Application Note must be distributed together; | | and 4) This Application Note may not be distributed for profit. | | | | Copyright 1992 Microsoft Corporation. All Rights Reserved. | | Microsoft, MS-DOS, QuickC, and QuickPascal are registered | | trademarks and Windows, QuickBasic, and Visual Basic are | | trademarks of Microsoft Corporation. | | | -------------------------------------------------------------------- APPLICABLE PRODUCTS =================== This application note applies to all versions of the following Microsoft language products: Microsoft Basic Microsoft C Microsoft C++ Microsoft COBOL Microsoft FORTRAN Microsoft Macro Assembler (MASM) Microsoft Pascal Microsoft QuickBasic(TM) Microsoft QuickC(C) Microsoft QuickC for Windows(TM) Microsoft QuickPascal(C) Microsoft Visual Basic(TM) TABLE OF CONTENTS ================== Section ------- Introduction 1 The Object Record Format 1 Frequent Object Record Subfields 1 Order of Records 1 Record Specifics 1 80H THEADR--Translator Header Record 1 82H LHEADR--Library Module Header Record 2 88H COMENT--Comment Record 2 88H IMPDEF--Import Definition Record (Comment Class A0, Subtype 01) 2 88H EXPDEF--Export Definition Record (Comment Class A0, Subtype 02) 2 88H INCDEF--Incremental Compilation Record (Cmnt Class A0, Sub 03) 2 88H LNKDIR--C++ Directives Record (Comment Class A0, Subtype 05) 2 88H LIBMOD--Library Module Name Record (Comment Class A3) 2 88H EXESTR--Executable String Record (Comment Class A4) 2 88H INCERR--Incremental Compilation Error (Comment Class A6) 2 88H NOPAD--No Segment Padding (Comment Class A7) 2 88H WKEXT--Weak Extern Record (Comment Class A8) 2 88H LZEXT--Lazy Extern Record (Comment Class A9) 3 88H PharLap Format Record (Comment Class AA) 3 8AH or 8BH MODEND--Module End Record 3 8CH EXTDEF--External Names Definition Record 3 8EH TYPDEF--Type Definition Record 3 90H or 91H PUBDEF--Public Names Definition Record 3 94H or 95H LINNUM--Line Numbers Record 3 96H LNAMES--List of Names Record 4 98H or 99H SEGDEF--Segment Definition Record 4 9AH GRPDEF--Group Definition Record 4 9CH or 9DH FIXUPP--Fixup Record 4 A0H or A1H LEDATA--Logical Enumerated Data Record 5 A2H or A3H LIDATA--Logical Iterated Data Record 5 B0H COMDEF--Communal Names Definition Record 5 B2H or B3H BAKPAT--Backpatch Record 5 B4H or B5H LEXTDEF--Local External Names Definition Record 5 B6H or B7H LPUBDEF--Local Public Names Definition Record 5 B8H LCOMDEF--Local Communal Names Definition Record 5 BCH CEXTDEF--COMDAT External Names Definition Record 5 C2H or C3H COMDAT--Initialized Communal Data Record 5 C4H or C5H LINSYM--Symbol Line Numbers Record 6 C6H ALIAS--Alias Definition Record 6 C8H or C9H NBKPAT--Named Backpatch Record 6 CAH LLNAMES--Local Logical Names Definition Record 6 Appendix 1: CodeView Extensions 6 Appendix 2: Microsoft MS-DOS Library Format 6 INTRODUCTION ============ This document is intended to serve a purpose that up until now has been performed by the LINK source code: to be the official definition for the object module format (the information inside .OBJ files) supported by Microsoft's language products. The goal is to include all currently used or obsolete OMF record types, all currently used or obsolete field values, and all extensions made by Microsoft, IBM, and others. The information provided here has been consolidated from many other documents: "The MS-DOS Encyclopedia" by Microsoft Press, an OMF386 document from IBM that was made available by the Joint Development Agreement, the "PharLap 386|Link Reference Manual," the Intel 8086 object module specification (Intel Technical Specification 121748- 001), and internal Microsoft documents. Where there have been conflicts, the current LINK source code has decided which information is correct. The audience for this document is expected to be technical, with background knowledge of the process by which source code is converted into an executable file in the MS-DOS or OS/2 environment. If you need more tutorial information, "The MS-DOS Encyclopedia" is a good place to start. THE OBJECT RECORD FORMAT ======================== Record Format ------------- All object records conform to the following format: <------Record Length in Bytes-----> 1 2 <variable> 1 Record Record Record Checksum or 0 Type Length Contents The Record Type field is a 1-byte field containing the hexadecimal number that identifies the type of object record. The Record Length field is a 2-byte field that gives the length of the remainder of the object record in bytes (excluding the bytes in the Record Type and Record Length fields). The record length is stored with the low-order byte first. An entire record occupies 3 bytes plus the number of bytes in the Record Length field. The Record Contents field varies in size and format, depending on the record type. The Checksum field is a 1-byte field that contains the negative sum (modulo 256) of all other bytes in the record. In other words, the checksum byte is calculated so that the low-order byte of the sum of all the bytes in the record, including the checksum byte, equals 0. Overflow is ignored. Some compilers write a 0 byte rather than computing the checksum, so either form should be accepted by programs that process object modules. NOTES The maximum size of the entire record (unless otherwise noted for specific record types) is 1024 bytes. For LINK386, the format is determined by the least-significant bit of the Record Type field. An odd Record Type indicates that certain numeric fields within the record contain 32-bit values; an even Record Type indicates that those fields contain 16-bit values. The affected fields are described with each record. Note that this principle does not govern the Use32/Use16 segment attribute (which is set in the ACBP byte of SEGDEF records); it simply specifies the size of certain numeric fields within the record. It is possible to use 16-bit OMF records to generate 32-bit segments, or vice versa. LINK ignores the value of the checksum byte, but some other utilities do not. Microsoft's Quick languages write a 0 byte instead of computing a checksum. FREQUENT OBJECT RECORD SUBFIELDS ================================ The contents of each record are determined by the record type, but certain subfields appear frequently enough to be explained separately. The format of such fields is below. Names ----- A name string is encoded as an 8-bit unsigned count followed by a string of count characters. The character set is usually some ASCII subset. A null name is specified by a single byte of 0 (indicating a string of length 0). Indexed References ------------------ Certain items are ordered by occurrence and are referenced by index. The first occurrence of the item has index number 1. Index fields may contain 0 (indicating that they are not present) or values from 1 through 7FFF. The index number field in an object record can be either 1 or 2 bytes long. If the number is in the range 0-7FH, the high-order bit (bit 7) is 0 and the low-order bits contain the index number, so the field is only 1 byte long. If the index number is in the range 80- 7FFFH, the field is 2 bytes long. The high-order bit of the first byte in the field is set to 1, and the high-order byte of the index number (which must be in the range 0-7FH) fits in the remaining 7 bits. The low-order byte of the index number is specified in the second byte of the field. The code to decode an index is: if (first_byte & 0x80) index_word = (first_byte & 7F) * 0x100 + second_byte; else index_word = first_byte; Type Indexes ------------ Type Index fields occupy 1 or 2 bytes and occur in PUBDEF, LPUBDEF, COMDEF, LCOMDEF, EXTDEF, and LEXTDEF records. They are encoded as described above for indexed references, but the interpretation of the values stored is governed by whether the module has the "new" or "old" object module format. "Old" versions of the OMF (indicated by lack of a COMENT record with comment class A1), have Type Index fields that contain indexes into previously seen TYPDEF records. This format is no longer produced by Microsoft products and is ignored by LINK if it is present. See the section of this document on TYPDEF records for details on how this was used. "New" versions of the OMF (indicated by the presence of a COMENT record with comment class A1), have Type Index fields that contain proprietary CodeView information. For more information on CodeView, see Appendix 1. NOTE: Currently, the linker does not perform type checking. Ordered Collections ------------------- Certain records and record groups are ordered so that the records may be referred to with indexes (the format of indexes is described in the "Indexed References" section of this document). The same format is used whether an index refers to names, logical segments, or other items. The overall ordering is obtained from the order of the records within the file together with the ordering of repeated fields within these records. Such ordered collections are referenced by index, counting from 1 (index 0 indicates unknown or not specified). For example, there may be many LNAMES records within a module, and each of those records may contain many names. The names are indexed starting at 1 for the first name in the first LNAMES record encountered while reading the file, 2 for the second name in the first record, and so forth, with the highest index for the last name in the last LNAMES record encountered. The ordered collections are: Names Ordered by occurrence of LNAMES records and names within each. Referenced as a name index. Logical Ordered by occurrence of SEGDEF records in Segments file. Referenced as a segment index. Groups Ordered by occurrence of GRPDEF records in file. Referenced as a group index. External Ordered by occurrence of EXTDEF, COMDEF, Symbols LEXTDEF, and LCOMDEF records and symbols within each. Referenced as an external name index (in FIXUP subrecords). Numeric 2- and 4-Byte Fields ---------------------------- Words and double words (16- and 32-bit quantities) are stored in Intel byte order (lowest address is least significant). Certain records, notably SEGDEF, PUBDEF, LPUBDEF, LINNUM, LEDATA, LIDATA, FIXUPP, and MODEND, contain size, offset, and displacement values that may be 32-bit quantities for Use32 segments. The encoding is as follows: - When the least-significant bit of the record type byte is set (that is, the record type is an odd number), the numeric fields are 4 bytes. - When the least-significant bit of the record type byte is clear, the fields occupy 2 bytes. The values are zero-extended when applied to Use32 segments. NOTE: See the description of SEGDEF records in this document for an explanation of Use16/Use32 segments. ORDER OF RECORDS ================ The sequence in which the types of object records appear in an object module is fairly flexible in some respects. Several record types are optional, and if the type of information they carry is unnecessary, they are omitted from the object module. In addition, most object record types can occur more than once in the same object module. And because object records are variable in length, it is often possible to choose between combining information into one large record or breaking it down into several smaller records of the same type. An important constraint on the order in which object records appear is the need for some types of object records to refer to information contained in other records. Because the linker processes the records sequentially, object records containing such information must precede the records that refer to the information. For example, two types of object records, SEGDEF and GRPDEF, refer to the names contained in an LNAMES record. Thus, an LNAMES record must appear before any SEGDEF or GRPDEF records that refer to it so that the names in the LNAMES record are known to the linker by the time it processes the SEGDEF or GRPDEF records. The record order is chosen so that linker passes through an object module are minimized. Microsoft LINK makes two passes through the object modules: the first pass may be cut short by the presence of the Link Pass Separator COMENT record; the second pass processes all records. For greatest linking speed, all symbolic information should occur at the start of the object module. This order is recommended but not mandatory. The general ordering is: Identifier Record(s) -------------------- NOTE: This must be the first record. THEADR or LHEADR record Records Processed by LINK Pass 1 -------------------------------- The following records may occur in any order but they must precede the Link Pass Separator if it is present: COMENT records identifying object format and extensions COMENT records other than Link Pass Separator comment LNAMES or LLNAMES records providing ordered name list SEGDEF records providing ordered list of program segments GRPDEF records providing ordered list of logical segments TYPDEF records (obsolete) ALIAS records PUBDEF records locating and naming public symbols LPUBDEF records locating and naming private symbols COMDEF, LCOMDEF, EXTDEF, LEXTDEF, and CEXTDEF records NOTE: This group of records is indexed together, so external name index fields in FIXUPP records may refer to any of the record types listed. Link Pass Separator (Optional) ------------------------------ COMENT class A2 record indicating that Pass 1 of the linker is complete. When this record is encountered, LINK stops reading the object file in Pass 1; no records after this comment are read in Pass 1. All the records listed above must come before this COMENT record. For greater linking speed, all LIDATA, LEDATA, FIXUPP, BAKPAT, INCDEF, and LINNUM records should come after the A2 COMENT record, but this is not required. In LINK, Pass 2 begins again at the start of the object module, so these records are processed in Pass 2 no matter where they are placed in the object module. Records Ignored by LINK Pass 1 and Processed by LINK Pass 2 ----------------------------------------------------------- The following records may come before or after the Link Pass Separator: LIDATA, LEDATA, or COMDAT records followed by applicable FIXUPP records FIXUPP records containing only THREAD subrecords BAKPAT and NBKPAT FIXUPP records COMENT class A0, subrecord type 03 (INCDEF) records containing incremental compilation information for FIXUPP and LINNUM records LINNUM and LINSYM records providing line number and program code or data association Terminator ---------- MODEND record indicating end of module with optional start address RECORD SPECIFICS ================ Details of each record (form and content), together with historical notes and comments on usage, are presented in the sections that follow. Conflicts between various OMFs that overlap in their use of record types or fields are marked. Below is a combined list of record types defined by the Intel 8086 OMF specification and record types added after that specification was finished. Titles in square brackets ([]) indicate record types that have been implemented and that are described in this document. Titles not in square brackets indicate record types that have not been implemented and are followed by a paragraph of description from the Intel specification. For unimplemented record types, a subtle distinction is made between records that LINK ignores and those for which LINK generates an "illegal object format" error condition. Records Currently Defined ------------------------- 6EH RHEADR R-Module Header Record This record serves to identify a module that has been processed (output) by LINK-86/LOCATE-86. It also specifies the module attributes and gives information on memory usage and need. This record type is ignored by Microsoft LINK. 70H REGINT Register Initialization Record This record provides information about the 8086 register/register-pairs: CS and IP, SS and SP, DS and ES. The purpose of this information is for a loader to set the necessary registers for initiation of execution. This record type is ignored by Microsoft LINK. 72H REDATA Relocatable Enumerated Data Record This record provides contiguous data from which a portion of an 8086 memory image may eventually be constructed. The data may be loaded directly by an 8086 loader, with perhaps some base fixups. The record may also be called a Load-Time Locatable (LTL) Enumerated Data Record. This record type is ignored by Microsoft LINK. 74H RIDATA Relocatable Iterated Data Record This record provides contiguous data from which a portion of an 8086 memory image may eventually be constructed. The data may be loaded directly by an 8086 loader, but data bytes within the record may require expansion. The record may also be called a Load-Time Locatable (LTL) Iterated Data Record. This record type is ignored by Microsoft LINK. 76H OVLDEF Overlay Definition Record This record provides the overlay's name, its location in the object file, and its attributes. A loader may use this record to locate the data records of the overlay in the object file. This record type is ignored by Microsoft LINK. 78H ENDREC End Record This record is used to denote the end of a set of records, such as a block or an overlay. This record type is ignored by Microsoft LINK. 7AH BLKDEF Block Definition Record This record provides information about blocks that were defined in the source program input to the translator that produced the module. A BLKDEF record will be generated for every procedure and for every block that contains variables. This information is used to aid debugging programs. This record type is ignored by Microsoft LINK. 7CH BLKEND Block End Record This record, together with the BLKDEF record, provides information about the scope of variables in the source program. Each BLKDEF record must be followed by a BLKEND record. The order of the BLKDEF, debug symbol records, and BLKEND records should reflect the order of declaration in the source module. This record type is ignored by Microsoft LINK. 7EH DEBSYM Debug Symbols Record This record provides information about all local symbols, including stack and based symbols. The purpose of this information is to aid debug- ging programs. This record type is ignored by Microsoft LINK. [80H] [THEADR] [Translator Header Record] [82H] [LHEADR] [Library Module Header Record] 84H PEDATA Physical Enumerated Data Record This record provides contiguous data, from which a portion of an 8086 memory image may be constructed. The data belongs to the "unnamed absolute segment" in that it has been assigned absolute 8086 memory addresses and has been divorced from all logical segment information. This record type is ignored by Microsoft LINK. 86H PIDATA Physical Iterated Data Record This record provides contiguous data, from which a portion of an 8086 memory image may be constructed. It allows initialization of data segments and provides a mechanism to reduce the size of object modules when there is repeated data to be used to initialize a memory image. The data belongs to the "unnamed absolute segment." This record type is ignored by Microsoft LINK. [88H] [COMENT] [Comment Record] [8AH/8BH] [MODEND] [Module End Record] [8CH] [EXTDEF] [External Names Definition Record] [8EH] [TYPDEF] [Type Definition Record] [90H/91H] [PUBDEF] [Public Names Definition Record] 92H LOCSYM Local Symbols Record This record provides information about symbols that were used in the source program input to the translator that produced the module. This information is used to aid debugging programs. This record has a format identical to the PUBDEF record. This record type is ignored by Microsoft LINK. [94H/95H] [LINNUM] [Line Numbers Record] [96H] [LNAMES] [List of Names Record] [98H/99H] [SEGDEF] [Segment Definition Record] [9AH] [GRPDEF] [Group Definition Record] [9CH/9DH] [FIXUPP] [Fixup Record] 9EH (none) Unnamed record This record number was the only even number not defined by the original Intel specification. Apparently it was never used. This record type is ignored by Microsoft LINK. [A0H/A1H] [LEDATA] [Logical Enumerated Data Record] [A2H/A3H] [LIDATA] [Logical Iterated Data Record] A4H LIBHED Library Header Record This record is the first record in a library file. It immediately precedes the modules (if any) in the library. Following the modules are three more records in the following order: LIBNAM, LIBLOC, and LIBDIC. This record type is ignored by Microsoft LINK. A6H LIBNAM Library Module Names Record This record lists the names of all the modules in the library. The names are listed in the same sequence as the modules appear in the library. This record type is ignored by Microsoft LINK. A8H LIBLOC Library Module Locations Record This record provides the relative location, within the library file, of the first byte of the first record (either a THEADR or LHEADR or RHEADR record) of each module in the library. The order of the locations corresponds to the order of the modules in the library. This record type is ignored by Microsoft LINK. AAH LIBDIC Library Dictionary Record This record gives all the names of public symbols within the library. The public names are separated into groups; all names in the nth group are defined in the nth module of the library. This record type is ignored by Microsoft LINK. [B0H] [COMDEF] [Communal Names Definition Record] [B2H/B3H] [BAKPAT] [Backpatch Record] [B4H] [LEXTDEF] [Local External Names Definition Record] [B6H/B7H] [LPUBDEF] [Local Public Names Definition Record] [B8H] [LCOMDEF] [Local Communal Names Definition Record] BAH/BBH COMFIX Communal Fixup Record Microsoft doesn't support this never- implemented IBM extension. This record type generates an error when it is encountered by Microsoft LINK. BCH CEXTDEF COMDAT External Names Definition Record C0H SELDEF Selector Definition Record Microsoft doesn't support this never- implemented IBM extension. This record type generates an error when it is encountered by Microsoft LINK. [C2H/C3] [COMDAT] [Initialized Communal Data Record] [C4H/C5H] [LINSYM] [Symbol Line Numbers Record] [C6H] [ALIAS] [Alias Definition Record] [C8H/C9H] [NBKPAT] [Named Backpatch Record] [CAH] [LLNAMES] [Local Logical Names Definition Record] [F0H] [Library Header Record] Although this is not actually an OMF record type, the presence of a record with F0H as the first byte indicates that the module is a Microsoft library. The format of a library file is given in Appendix 2. [F1H] [Library End Record] 80H THEADR--TRANSLATOR HEADER RECORD ==================================== Description ----------- The THEADR record contains the name of the object module. This name identifies an object module within an object library or in messages produced by the linker. History ------- Unchanged. Record Format ------------- 1 2 1 <-String Length-> 1 80 Record String Name String Checksum Length Length The String Length byte gives the number of characters in the name string; the name string itself is ASCII. This name is usually that of the file that contains a program's source code (if supplied by the language translator), or may be specified directly by the programmer (for example, TITLE pseudo-operand or assembler NAME directive). NOTES The name string is always present; a null name is allowed but not recommended (because it doesn't provide much information for a debugging program). In object modules generated by Microsoft compilers, the name string indicates the full path and filename of the file that contained the source code for the module. This record, or an LHEADR record must occur as the first object record. More than one header record is allowed (as a result of an object bind, or if the source arose from multiple files as a result of include processing). Examples -------- The following THEADR record was generated by the Microsoft C Compiler: 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 80 09 00 07 68 65 6C 6C 6F 2E 63 CB ...hello.c Byte 00H contains 80H, indicating a THEADR record. Bytes 01-02H contain 0009H, the length of the remainder of the record. Bytes 03-0AH contain the T-module name. Byte 03H contains 07H, the length of the name, and bytes 04H through 0AH contain the name itself (HELLO.C). Byte 0BH contains the Checksum field, 0CBH. 82H LHEADR--LIBRARY MODULE HEADER RECORD ======================================== Description ----------- This record is very similar to the THEADR record. It is used to indicate the name of a module within a library file (which has an internal organization different from that of an object module). History ------- This record type was defined in the original Intel specification with the same format but with a different purpose, so its use for libraries should be considered a Microsoft extension. Record Format ------------- 1 2 1 <-String Length-> 1 82 Record String Name String Checksum Length Length NOTE: In LINK, THEADR, and LHEADR records are handled identically. See Appendix 2 for a complete description of Microsoft's library file format.